Julian Sparber [Mon, 19 Feb 2024 14:15:48 +0000 (15:15 +0100)]
shell/global: Don't force active workspace for launch context
Since the launch context may also be used to activate an action on an
running application with an already existing window, which we don't
necessarily want to move to a different workspace, don't set a workspace
for the launch context. If no active window exists for an application
then it will be place on the currently active workspace anyways.
Julian Sparber [Mon, 19 Feb 2024 08:30:25 +0000 (09:30 +0100)]
shell/app: Add method to activate an action via FDO DBus activation
There are multiple different places where we activate an app action,
but none set the correct activation token. Therefore this adds an async
method to to call `ActivateAction` on `org.freedesktop.Appliaction`
with the correct activation token/startup id as platform data.
Florian Müllner [Fri, 23 Feb 2024 23:00:34 +0000 (00:00 +0100)]
ci: Don't install entire Development group
With dependencies, the group pulls in about 150 packages. We only
need a tiny tiny subset of that, so only specify what we really
need to not blow up the image size unnecessarily.
We auto-close FDO notifications when the sender leaves the bus,
given that the protocol was created without persistency in mind
and any action will become invalid.
However that broke when moving the public-facing implementation
into a separate service, as we now track the (always running)
service instead of the original sender.
Fix that by forwarding the sender to the internal implementation
via a private hint, just like we already do for the PID.
Florian Müllner [Tue, 20 Feb 2024 18:39:31 +0000 (19:39 +0100)]
notificationDaemon: Namespace private `sender-pid` hint
The hint is a private implementation detail between the public
and internal services, not something anybody else should set
(*cough* libnotify *cough*).
The vfunc was used to register profiling hooks for glx.swapComplete
as we have sysprof nowadays and as that code path is x11 specific
anyways, let us drop it
Julian Sparber [Tue, 20 Feb 2024 10:55:06 +0000 (11:55 +0100)]
components/networkAgent: Fix small mistake
Fixes: c1ff00c01 ("notification: Use the same Source for showing system notifications")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3200>
Ray Strode [Mon, 15 May 2023 14:48:15 +0000 (10:48 -0400)]
authPrompt: Disregard smartcard status changes if VERIFICATION_IN_PROGRESS
commit c8bb45b41c3a13ef161103f649aa18938e028a70 introduced a new
verification state, VERIFICATION_IN_PROGRESS, to detect when the user
has already interacted with the authentication prompt, so the
prompt can rate limit the number of times the user can cancel
authentication attempts with the escape key (without also rate limiting
the number of times they can hit escape to go back to the clock without
interacting with the prompt).
That means there are now two states that represent the user actively
undergoing verification: VERIFYING and VERIFICATION_IN_PROGRESS.
It's inappropriate to reset the smartcard service if the user is
actively conversing with it. We try to check for that by looking at the
original verification state, VERIFYING, but we unfortunately, neglect
to account for the new VERIFICATION_IN_PROGRESS state.
The result is that if a user types their smartcard pin at the clock,
and then inserts their smartcard, the pin will get cleared instead of
used, and they have to retype it again.
This commit fixes the oversight, and allows users to again pre-type
their smartcard pin at the clock before inserting their smartcard.
Florian Müllner [Tue, 17 Dec 2019 19:06:24 +0000 (20:06 +0100)]
sessionMode: Use property spread to sync mode
The parameters here come from a fixed set of mode definitions rather
than a function parameter, so the additional check performed by
Params.parse() isn't relevant here.
As we are slowly moving colors to be represented by a [0, 1] floats.
The unsigned integer variant will likely be removed in the near future, so be
ready for that already
The button that clear notifications is labeled as
"Clear". When using a screen reader, this label
doesn't provide enough context about the action
that will happen.
Florian Müllner [Fri, 9 Feb 2024 23:58:27 +0000 (00:58 +0100)]
extensionSystem: Support locking down extension installation
Currently extensions can only be locked down completely by
restricting the `enabled-extensions` key via dconf.
This is too restrictive for environments that want to allow users
to customize their system with extensions, while still limiting
the set of possible extensions.
To fill that gap, add a new `allow-extension-installation` setting,
which restricts extensions to system extensions when disabled.
As the setting is mainly intended for locking down by system
administrators, there is no attempt to load/unload extensions
on settings changes.
Florian Müllner [Tue, 13 Feb 2024 23:00:48 +0000 (00:00 +0100)]
st/drawing-actor: Queue redraw when repainting
Commit e7734e30bd removed the clutter_content_invalidate() call
that took care of queuing a redraw for us. Now that we no
longer delegate to a content we have to do that ourselves.
Florian Müllner [Mon, 12 Feb 2024 13:13:07 +0000 (14:13 +0100)]
tools/toolbox: Expose --reconfigure meson flag
It turns out that nowadays meson updates don't always require
a full wipe of an existing build dir, but `--reconfigure` is
often enough. So let's expose that flag as well.
Jonas Dreßler [Mon, 2 Oct 2023 12:30:08 +0000 (14:30 +0200)]
screenshot: Also do pipeline fallback on screencast crashes during startup
Since the last commit, we have infrastructure in place in the ScreencastService
to blocklist pipelines which crashed the recorder.
If such a crash happens a few minutes into a screencast, we can't do any better
than telling the user about the problem and encouraging them to try again (with
the faulty pipeline now blocklisted).
If the crash happens while starting the recording though, we can actually do
better: We can try to auto-restart the ScreencastService ourselves, and the
recording might still succeed without the user noticing anything. So retry
that start of the recorder for two more times, and then finally give up.
Jonas Dreßler [Thu, 19 Oct 2023 14:09:00 +0000 (16:09 +0200)]
screenshot: Blocklist the current screencast pipeline if recorder failed
When gstreamer crashes during recording, it pulls the whole screencastService
down with it.
These crashes are typically caused by the gstreamer pipeline that's in use,
so to avoid running into them again and again, we can blocklist the last
used pipeline in case the recorder didn't shut down (aka crashed) last time.
To store this state, create a file (gnome-shell-screencast-pipeline-blocklist)
in the XDG runtime dir and store the ID of the current pipeline in that file
before we try to start.
Now when we crash while running the pipeline, the entry in that file will stay
around and we'll pick it up on the next start of the screencastService as a
blocklist.
When the recording was successful on the other hand, we'll call
`this._updateServiceCrashBlocklist([...this._blocklistFromPreviousCrashes])`
and remove the new entry from the file again before shutting down the recorder.
In addition to that, we can now encourage the user to try recording again
after a crash happened. Adjust the failure notification a bit to say
"please try again".
Jonas Dreßler [Mon, 2 Oct 2023 12:00:45 +0000 (14:00 +0200)]
screenshot: Show a special error when screencast ran out of disk space
Since we now propagate error types back to gnome-shell now, let's start
with showing a special error message in case the disk ran out of space,
which is probably the most typical error.
Jonas Dreßler [Wed, 7 Feb 2024 11:05:47 +0000 (12:05 +0100)]
screenshot: Handle screencast startup failures using special notification
When the screencast fails to start, we currently don't really inform the
user, other than the red screencasting indicator in the panel going away.
Re-use the failure handling paths to also show a notification when the
screencast fails to start. The notification in this case obviously should
not have an action to open a file (there is no file), so make that depend
on whether this._screencastPath is set and unset the path.
Jonas Dreßler [Sun, 1 Oct 2023 18:10:33 +0000 (20:10 +0200)]
screencastService: Propagate machine-parseable error types to gnome-shell
We'll be using hardware encoding for screencasts soon, so we'll likely see
more things go wrong in the future, including crashes of the whole
screencastService. To deal with this, we'll introduce logic to blocklist
certain recording pipelines in case of failure and also add some logic
to retry the recording automatically.
To allow for better messaging to the user in those failure cases, we want
to be aware in gnome-shell, what exactly the error in the recorder was.
So propagate the most common types of errors that can happen in the
ScreencastService to gnome-shell using the new DBusError module.
Florian Müllner [Tue, 6 Feb 2024 17:16:29 +0000 (18:16 +0100)]
notification: Pass policy in the Source contructor
Commit 932ccac1 changed Source to use a regular constructor
instead of `_init()`.
Unfortunately that results in ordering issues for subclasses
that override `_createPolicy()`, if that method needs to access
any properties that are set in the constructor (as `this` is
only available after chaining up to the parent).
We can fix that by simply setting the policy from the constructor,
instead of relying on some overriden method being called.
projects / gnome-shell.git / log